1. Field of the Invention
The subject disclosure relates to middleware for communication networks, and more particularly to an improved middleware application for facilitating operation between low level and high level hardware drivers.
2. Background of the Related Art
For companies with more than a handful of employees, connecting every employee's telephone to the public telephone network is not practical because the public telephone network applies a monthly charge to each line. Moreover, internal calls would require dialing every digit and if the company is spread across several locations, inter-location calls would be assessed long distance charges. As a result, companies establish a private business exchange (hereinafter referred to as “PBX” but also known as “PABX”).
The PBX is a telephone switching center owned by the company rather than the common carrier. Various locations of the company can be interconnected by a dedicated line such as a trunk line so that the PBX can encompass the entire company. Users of the PBX share a certain number of outside lines for making and receiving telephone calls external to the PBX. The PBX performs a variety of functions, such as establishing and maintaining connections or circuits between the telephones of two users. Facsimile machines, communication modems and other communication devices can be connected to the PBX as desired. The PBX also provides other features such as usage information for accounting purposes, speed dialing, call forwarding, music on hold and the like.
Referring to FIG. 1, a high-level view of an environment including a PBX 110 is referred to generally by the reference numeral 100. An electronic rack 102 houses the required software and hardware for the PBX 110 to properly operate the telephones 104, and communicate with the computers 106, facsimile machines 108 and other networks 114. In this sense, the electronics rack 102 holds at least one server. It will be appreciated that “server” refers to the program that is managing the associated resources and that several “servers” may be incorporated within one physical component or alternatively multiple components may be coupled to execute a single “server” program in order to accomplish the desired performance.
The other networks 114 could include telco networks, WAN, LAN, the Internet and the like. It is to be appreciated that where only one telephone 104, one computer 106 and one facsimile machine 108 are shown for simplicity, several hundred or more of each of these could actually be utilized. The interface that allows each of the components to communicate is often proprietary to the manufacteror and, therefore, connected devices must comply with the protocol. The PBX can alternatively use a standard interface that supports connection with many devices. ISDN and T1 are common digital standards for fixed devices. For simplicity, all of the switching equipment is shown within the electronic rack 102 but it would be appreciated by those of ordinary skill in the pertinent art that such localization is not required. The clients 104 may be stand alone desktop personal computers, part of a network or like arrangement. It is also envisioned that the environment 100 has routers, firewalls, subnets, buffers, buses, balancers, and like devices as would be appreciated by one of ordinary skill in the pertinent art. For clarity, such devices are not illustrated.
The electronic rack 102 houses additional hardware in a plurality of electronic racks 112. The hardware contains memory for storing the software that provides the desired features. For example, a voicemail module is a common specific application with dedicated hardware that mimics the functions of an answering machine from a centralized location rather than at each desktop. In order for the voicemail module to communicate with the other components of the PBX, the communication protocols must be defined. An Application Programming Interface (hereinafter “API”) is a set of definitions of the ways in which the various modules communicate with each other. In effect, the API bridges the communication gap between lower-level and higher-level software. Typically, the API provides a set of commonly-used functions so that programmers can utilize the provided functions without having to reinvent every function. Often, a program written for a first API will not work directly with another second API without an intermediate layer that adapts the program for use with the second. A commonly used API is the CAPI standard available from Eicon Networks. For telephony on Microsoft Windows platforms, TAPI is a commonly used API. TAPI is middleware between the device drivers of actual hardware such as modems, and the high-level applications.
In view of the above, several systems have been developed to further enhance and increase the functionality of the PBX. Many electronics racks 102 contain a plurality of communication cards such as basic rate interface, primary rate interface, Analog, Robbed Bit Signalling etc (hereinafter “BRI”) cards for accessing channels associated with each BRI card. There are problems associated with multiple BRI cards because each BRI card is busy while the associated channel is in use. While a BRI card is busy, an API recognizes the BRI card as unable to be selected as a free and operable card. As a result, a delay may occur as an API searches card by card for an available BRI card. There is a need, therefore, for an improved module which permits utilizing communication cards in a flexible arrangement so that the PBX capabilities can be efficiently utilized.
In addition, a BRI card can often hang in an inoperable state or actually be removed from the electronics rack 102. In the prior art, if the BRI card is called, the API that is attempting to utilize the BRI card may not be able to successfully recognize the error and properly handle corrective action. If the BRI card is merely hung up, no middleware is in place to reload and restart the problematic card. Further, new BRI cards may be installed without proper execution of the loading and activation procedure. As a result, the newly added BRI cards would not be operational. Thus, there is a need to isolate the BRI cards from the upper level API in order to insure proper operation. The isolation module can further recognize and activate newly added or problematic cards, provide error messages to the upper level API when hung up BRI cards are called and prevent further calls of inoperable BRI cards.
Still further, when the PBX switch does not support conference calling and transferring calls, an attempt at accomplishing the same results in failure. Thus, there is a need for a software module that can detect the failure and overcome said failure to establish the desired conference call or transfer.
In addition, calls are often redirected multiple time through multiple PBX to finally arrive at an adapter module. The originator PBX typically sends a path replacement proposal to the real destination of the call and a special application is required to handle the path replacement proposal. There is a need, therefore, for an adapter module that can transparently handle the path replacement proposal.